In the field of software engineering, complex, large-scale software development projects can be difficult to manage. Ideally, the design of a software system is kept as modular or layered as possible in order to reduce interdependencies among subsystems. These interdependencies, especially cyclical ones, can be difficult to manage. A modular software system is easier to manage because the different modules, or subsystems, can be modified, removed and replaced without affecting too many other parts of the software system. While the architect of a software system might design the system to be modular initially, changes going into the system through time pressures and employee turnover in the software development team tend to decrease the modularity of the system. Subsystems become more interdependent over time as other priorities take precedence over maintaining the modularity of the system, resulting in greater likelihood of problems being introduced into the system. Further, as fewer software developers have knowledge of the overall system, the system becomes even more difficult to maintain. As the dependency structure of the software system becomes more complex, the system becomes more difficult to maintain. A desirable goal is to be able to manage this dependency structure adequately.
Relationships between different parts of a software system have been displayed diagrammatically in several ways in the prior art. As an example, FIG. 1 illustrates an example provided by HEADWAY REVIEW™ (from Headway Software, Waterford, Ireland). A directed arrow, such as directed arrow 102, shows that the subsystem at the source of the arrow, such as source subsystem 104, depends on the subsystem at the target of the arrow, such as target subsystem 106. Furthermore, HEADWAY REVIEW™ also allows a user to display what the dependency is. For a software system written in an object oriented language such as Java, some dependencies may be method calls or references to the fields of an object or inheritance relationships. The complexity of displaying inter-relationships, for even the limited nine subsystem system of FIG. 1, is evident.
FIGS. 2A and 2B from Yassine 2004 (Ali Yassine, “An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method”, Quaderni di Management (Italian Management Review), <www.quaderni-di-management.it>, Nov. 9, 2004) is a prior art description of a system containing two subsystems. Dependency relationships between the subsystems are one of three possible types. In FIG. 2A, the Graph Representation 200 chart of these three types of relationships shows the two systems in a Parallel 202 relationship where neither subsystem A nor subsystem B depend on the other, a Sequential 204 relationship where subsystem B depends on subsystem A, but subsystem A does not depend on subsystem B, and a Coupled 206 relationship where subsystems A and B each depend on the other.
The types of directed graphs shown in FIG. 2A, also known as digraphs, may also be rendered in the form of a matrix, known as a Design Structure Matrix, or DSM as shown in FIG. 2B.
One way to address the dependency structure of a software system is to model the software system through the use of dependency matrices such as the design structure matrix or the dependency structure matrix (DSM). The approach is to decompose the system into subsystems and then to use the DSM to indicate the coupling between the subsystems to show the dependencies. A DSM is a square, symmetric matrix where a subsystem of a given system is placed as a header of a row of the matrix, and as a header of a column of the matrix. The row and column order of the subsystems is the same so that each subsystem is shown with a row named on the left and is shown with a column named at the top. Typically, the DSM is a binary matrix, where matrix cells contain either a 1 or a 0, or equivalently, an ‘X’ or the absence of any character. An indicator located at a grid location having commonality with a row and a column indicates a dependency of the subsystem associated with the row on the subsystem associated with the column. The indicators such as ‘X’ or ‘1’ of these dependencies are also known as dependency marks. The dependency marks can represent various criteria such as the strength of the dependency between the two subsystems in the row and column associated with a particular grid location. In DSMs that incorporate hierarchy the dependency indication can also be an aggregation of dependencies between the all the elements of the hierarchy represented by the row and column subsystems.
The DSM Representation 250 of the digraph Parallel 202 relationship corresponds to the DSM Parallel 252 relationship, the digraph Sequential 204 relationship to the DSM Sequential 254 relationship, and the digraph Coupled 206 relationship to the DSM Coupled 256 relationship.
In the Sequential 254 DSM representation, the subsystem A does not depend on subsystem B. Consequently, the cell in the row with A in the header, and the column with B in the header is empty, having no dependency mark. The contents of the cells in a row associated with a subsystem indicate what other subsystems the subsystem in the row header depends upon. Similarly, the contents of cells in a column associated with a subsystem indicate for the subsystem in the column header what other subsystems depend upon the subsystem in the column header. For the row with the header B in the Sequential 254 DSM representation, the ‘X’ in the cell corresponding to the row B and the column A indicates that B depends on A. Cells where A intersects itself and B intersects itself are rendered in black. As dependency of a given subsystems upon itself is generally of lesser interest in the types of analysis enabled by DSM, these are frequently drawn as black, or with a period or a dot.
FIG. 3A, taken from Maurer et. al. (Maik Maurer, Udo Pulm, Udo Lindemann, “Tendencies toward more and more flexibility”, 2003) includes a prior art engineering DSM 310 showing a dependency model of an automotive mechanical system with a limited use of hierarchy. Elements of the engineering DSM 300 correspond to a mixture of Subsystems (Components), Functions, and Requirements. The Maurer engineering DSM 310 shows the interrelatedness between these different aspects of an automotive design.
The Maurer engineering DSM 310 represents hierarchy with names of parents 315 (component 320, function 330, and requirement 340) to the DSM elements rotated 90 degrees. DSM element parents 315 are not represented in the DSM 310 distinctly, only through children. For example component 320 is represented through children pump 321, engine 322, cylinder 323, casing 324, piston 325, and wheels 326. However, the parent elements 315 are essentially separate aspects of the design, and not hierarchal within any of the three aspects. Further, the Maurer engineering DSM is limited to two levels. FIG. 3B from Maurer et al. illustrates an engineering DSM 350 showing a dependency model of a mechanical system with limited use of hierarchy in the DSM. FIG. 3 contains a two level component hierarchy where both parents, for example, pump 360, and children, for example, centrifugal pump 362 and plunger pump 364, in the hierarchy each have their own row and column for displaying dependencies. Representation shows hierarchy Parents grayed but in same list with children.
Engineering DSM 370 shows a hierarchy where parent grid cells have a gray background color, but indicate dependencies by inclusion of Xs that are redundant with the X-indicated dependencies for the children. Engineering DSM 370 is similarly a two-level display. FIG. 4 is a prior art diagram from Sabbaghian et al. 1998 (Sabbaghian, Nader, Eppinger, Steven D., and Murman, Earll, “Product Development Process Capture & Display Using Web-Based Technologies”, Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics, San Diego, Calif., Oct. 11-14, 1998, pp. 2664-2669) showing conceptually how DSM's may be thought of as a hierarchy through a series of completely separate DSM's representing different levels of hierarchy. However, any hierarchy in FIG. 4 is shown in separate DSM's. There is no rendering mechanism implied other than separate DSM's.
FIG. 5 is an illustration of a prior art DSM 500 from Dong 1999 (Qi Dong—“Representing Information Flow and Knowledge Management in Product Design Using the Design Structure Matrix,” MIT ME Dept SM Thesis, January, 1999) showing how a second level of hierarchy may be provided by coloring the row and column headers with different colors. In this illustration, DSM 500 contains four top level subsystems (spatial function 510, sheet metal 520, electrical 530, and moveable glass 540) each having children, for example sheet metal function subsystem 520 with children including outer panel shape subsystem 522, pillars 524, halo 526, etc. The four top level subsystems are differentiated by color. However, this is also a two-level display.
Traditionally, databases are represented visually using Entity-Relationship (ER) Diagrams. These diagrams use boxes and arrows to represent database entities and the relationships between them. For instance, database tables are represented as boxes and a foreign key relationship is represented by a connecting arrow between the boxes. FIG. 6 shows a typical ER Diagram, such as in Computer Associates' ERWin product. Each Customer has a unique customer number and makes multiple payment transactions where each transaction is made by a specific customer identified by a customer number. Here the database tables are represented by rectangles and the relationship between them is represented by connecting lines. As the number of tables and their relationships increase these diagrams become hard to understand and to manage. Furthermore, these diagrams normally do not display many important elements of the database such as packages, sequences and stored procedures. They also do not display the relationships between many of these elements of the database. For instance, a stored procedure calling another stored procedure or a stored procedure referencing a table is not represented in ER diagrams.
Constructing a DSM where all the elements of the database are laid out in a flat structure would make the matrix large and hard to use. It is also important to construct a hierarchy that groups together related elements. There is no prior art guidance on how the hierarchy should be created for DSMs for databases. Another difficulty in representing a database system and discovering optimal groupings of subsystems is related to the difficulty of processing “Synonyms”. Synonyms are database elements that are aliases for other elements of the database. Appropriate placement of Synonyms in the database hierarchy is crucial to understanding the relationship between various elements of the database.
New frameworks have been created to simplify programming with object oriented languages such as Java and .NET. The Spring Framework is one such example. Spring Framework defines entities called ‘Spring Beans’ which are managed by the Spring Framework. Users of Spring Framework specify Spring Beans in configuration files with each configuration being used to specify one or more beans. Typically, Spring Beans are visualized in network diagrams that depict beans as rectangles and relationship between them as connecting lines, as shown in FIG. 7. As the number of beans becomes large it becomes hard to make sense of these diagrams. Often, users of Spring Framework will specify related or similar Spring beans in the same configuration file. However, these diagrams do not take into account the file where the bean was specified. These diagrams also do not show the implementation class that is associated with the Spring Bean.
Most large enterprises employ a variety of systems that are often coupled to each other. For instance, there are many mission critical applications that might access data from a variety of databases. Normally, these are modeled separately. For instance, the application architecture might be modeled with UML while the data architecture might be modeled with ER diagrams. Another example of how systems are coupled together is applications created with frameworks such as Spring and Hibernate. Applications written in Java use the Spring Framework to manage and improve coupling between objects. However, Spring itself uses entities called “Spring Beans” which are related to Java classes and to other Spring Beans. As are result, it is desirable to view the architecture in terms of elements from the Spring Framework and from Java.
A difficulty in using DSMs for representing databases and multi-domain systems is the large number of total elements and the fact many of the elements might be organized in a flat structure. For example, a database schema might contain hundreds of tables; or a database itself might be composed of hundreds of schemata. Often, there are only a few relationships between them. The large number of elements also makes it hard to visualize how changing one element will affect which other elements.